1. Field of the Invention
The present invention relates to a computer system, method and computer-readable article of manufacture for accessing shared data. More particularly, the present invention relates to allowing exclusive access to shared data.
2. Description of Related Art
A critical section of a computer is a section in a computer in which simultaneous performance of multiple processes using a single resource would lead to crash. In the critical section, atomicity needs to be secured by a measure such as performing exclusive control. In such exclusive control, a lock is used, for example. However, exclusive control using a lock poses a problem in that processing cannot be stopped in the middle in a critical section.
Such a critical section is, for example, a synchronized block in Java™. Java™ supports multi-thread programs at the language level. Java™ provides java.lang.Thread.interrupt as an application program interface (API) for asynchronously stopping a thread. Here, “to stop a thread” means to bring execution of the thread back to a certain part of a program, or to end execution of the thread. However, the above API cannot stop any thread other than a thread monitored for its interruption by use of the java.lang.Thread.interrupted method, and threads having been in a waiting state by calling java.lang.Object.wait, java.lang.Thread.join and java.lang.Thread.sleep. Even when such a thread is successfully stopped, if the thread is stopped in the middle of accessing shared data in a synchronized block which is a critical section in Java™, the shared data is left half-finished. This can lead to a condition where execution of other threads referring to the shared data is uncertain. To prevent this, if a thread is stopped, shared data needs to be returned to a state before execution of the synchronized block. However, it is unrealistic for a program to grasp all the updates of shared data in the synchronized block and to add a rollback process to each point where a thread is to be stopped.
Realtime Java™ provides javax.realtime.RealtimeThread.interrupt as an API for asynchronously stopping a thread. When this API is called, an asynchronous-event flag is set on a thread. An asynchronous-event checking code, which is automatically inserted in a byte code and in a just-in-time (JIT) compile code, is executed in each thread. By the execution of the asynchronous-event checking code, the presence or absence of an asynchronous event is checked. If there is a thread confirmed to have a flag set for it, an exception is thrown from this confirmed thread. Then, execution of this confirmed thread is brought back to a certain part of a program or is ended. However, an exception is not necessarily thrown in a synchronized block. This is because shared data cannot be returned to a state before execution of the synchronized block.
Because shared data protected by a synchronized block cannot be returned to a state before execution of the synchronized block in the conventional techniques, a thread cannot be stopped in a synchronized block.
There are examples of execution schemes for a critical section as alternatives to the above exclusive control schemes using a lock. A transactional memory scheme is employed in each of Non-patent Documents (1), Adam Welc, Antony L. Hosking and Suresh Jagannathan, “Transparently Reconciling Transactions with Locking for Java Synchronization,” ECOOP '06, Springer-Verlag Berlin Heidelberg, pp. 148-173, 2006, and (2) Brian Goetz, “Optimistic Thread Concurrency: Breaking the Scale Barrier,” AZUL SYSTEMS, pp. 1-11, January 2006. In the transactional memory scheme, a synchronized block is executed as a transaction. In Non-patent Documents (1) and (2), however, only a synchronized block in which a large number of lock contentions occur is executed as a transaction. This is because, if a synchronized block in which no or few lock contentions occur is executed as a transaction, this can lead to performance degradation as a result of the overhead of logging. Additionally, in Non-patent Documents (1) and (2), there is no mention of stopping a thread in a synchronized block. Further, Non-patent Documents (1) and (2) propose switching an execution scheme of a synchronized block between an exclusive control scheme and a transaction scheme.